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Abstract — This  paper  takes  care  of  an  evolution  of  web 
architecture  for  Telematics  services  on  ubiquitous  environments. 
Telematics  has  become  one  of  upcoming  convergence  fields  where 
many  kinds  of  services  are  now  be  operated  or  planned  to  be 
launched.  However,  most  of  Telematics  services  are  currently 
operated  in  a  closed  architecture:  they  require  hardware  and 
software  configurations  exclusively.  In  order  to  achieve 
ubiquitous  capabilities  in  Telematics  model,  this  paper  proposes 
a  web  service  platform  for  Telematics  based  on  web  service 
architecture.  With  the  proposed  Telematics  service  broker, 
service  providers  can  register  their  services,  and  service 
consumers  can  find  what  services  are  available  and  how  to  use 
them.  Adopting  open  architecture,  the  platform  will  contribute  to 
efficient  provision  of  Telematics  services  in  upcoming  ubiquitous 
environments. 

Keywords-Telematics;  ubiquitous;  web  service ;  platform;  XML; 
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I.  Introduction 

Next  generation  technologies  have  been  receding  into 
background  of  our  lives.  Ubiquitous  computing,  “Invisible, 
everywhere  computing  that  does  not  live  on  a  personal  device 
of  any  sort,  but  is  in  the  woodwork  everywhere,”  pursues  smart 
environments  [8].  In  such  a  space,  several  devices  will 
typically  have  to  work  together  to  perform  a  particular  task 
without  awareness  of  human  beings.  Dynamically  collecting  a 
group  of  smart  devices  to  enable  an  interaction  or  to  perform  a 
perceptual  task  requires  a  shared  computational  substrate  that 
allows  the  devices  to  communicate  bits  that  represent  concepts 
in  a  shared  ontology  [9].  These  calm  technologies  suggest  an 
importance  of  an  explicit  geometric  and  geographic  model  for 
pervasive  information,  a  representation  of  physical 
relationships  between  people,  things,  and  devices.  Moreover,  in 
order  to  achieve  an  extensible  and  casual  access  to  computing, 
much  attention  should  be  paid  on  the  geographic  points. 

With  respect  to  geospatial  features,  Open  Geospatial 
Consortium  (OGC)  and  International  Organization  for 
Standardization  (ISO)  have  promoted  research  projects  and 
proposed  recommendations  and  implementation  specifications 
for  interoperable  distribution  of  spatial  and  traffic  information 
based  on  XML  Web  service  technologies.  The  OpenGIS 
Service  Framework  is  concerned  with  the  functional 
decomposition  of  the  system  into  a  set  of  services  that  interact 
at  interfaces  without  regard  to  distribution  [10].  It  also  defines 


the  core  concept  of  services,  interfaces,  and  operations,  and 
then  describes  the  Publish-Find-Bind  mechanism  that 
represents  the  interactions  among  different  services.  Recently, 
Telematics  has  become  one  of  upcoming  convergence  fields 
where  many  kinds  of  technologies  such  as  Geographic 
Information  System  (GIS),  mobile  communication,  positioning 
technology,  and  multimedia  service  are  combined.  Telematics 
with  GIS  and  Web  services  technologies  has  promoted  the 
spread  of  geographic  and  vehicular  information  widely  and 
supported  various  kinds  of  driving  services.  However,  most  of 
currently  operated  Telematics  services  have  closed  architecture. 
They  exclusively  use  their  respective  data,  hardware 
configurations,  communication  environments,  and  client 
terminals.  Therefore  a  service  user  who  wants  to  change  the 
service  provider  cannot  use  his  current  environment,  and  may 
change  terminal,  software,  and  all  others  that  are  necessary. 
Such  incompatibility  brings  obstacles  to  interact  between 
systems,  things,  and  devices,  which  make  people  be  faced  with 
unveiled  seams  between  disappearing  technologies. 

We  take  care  of  an  evolution  of  web  architecture  for 
Telematics  services  on  ubiquitous  environments.  This  paper 
proposes  an  open  architecture  for  Telematics  services  based  on 
web  service  architecture,  which  enables  many  service  providers 
and  consumers  to  request  and  response  in  standardized  manner. 
The  architecture  also  contains  a  design  of  methods  representing 
request  and  response  of  Telematics  service  by  XML  schema. 
Prior  example  of  similar  approach  can  be  found  in  the  case  of 
Web  Feature  Service  (WFS)  specification  [1,  2].  In  order  to 
maximize  the  benefit,  this  paper  proposes  a  smart  web  platform 
that  can  manage  multiple  service  providers,  consumers,  their 
connections,  and  service  distribution  in  an  open  environment. 
Based  on  the  web  service  architecture,  the  Telematics  service 
platform  provides  XML  Web  services  by  exposing  useful 
functionality  to  web  users  through  a  standard  web  protocol. 
Also,  to  verify  the  architecture  of  the  proposed  service  platform, 
we  implement  a  prototype  route  service  system  and  apply  it  to 
the  service  platform  as  a  service  provider. 

The  rest  of  this  paper  is  organized  as  follows.  Section  2 
describes  the  proposed  service  platform  in  detail.  In  Section  3, 
operating  functionalities  of  the  proposed  platform  are  described. 
Section  4  shows  an  entire  implementation  of  the  web  platform 
including  Telematics  route  service.  Finally,  we  conclude  this 
paper  in  Section  5. 
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II.  Smart  Web  Platform  For  Telematics  Service 

A  basic  concept  of  the  service  environment  is  based  on  the 
Web  Service  Architecture  (WSA)  with  Publish-Find-Bind 
mechanism  [3].  Service  providers  can  register  their  services, 
and  service  consumers  can  find  what  services  are  available  and 
how  to  use  them.  The  architecture  can  support  an  extensible 
environment  with  interactions  of  roles  to  perform  basic 
operations;  it  identifies  common  elements  of  global  web 
services  network  that  are  required  to  ensure  interoperability 
between  web  services.  In  this  section,  we  describe  a  scheme  for 
requesting  and  responding  services  in  a  standardized  manner 
adapting  XML  to  Telematics  service  and  an  architecture  that 
enables  many  servers  and  users  to  request  and  response  using 
XML. 

With  open  standards  and  interests  in  communication  and 
collaboration  among  services,  the  service  platform  is  expected 
to  become  a  suitable  framework  for  service  integration  and 
extension. 

In  actual  services  of  telematics,  there  may  be  various  types 
of  terminals  and  communication  environments.  Therefore,  a 
service  platform  should  consider  and  manage  information 
about  heterogeneous  clients.  We  assume  that  a  service  provider 
should  define  the  possible  terminal  type(s)  and  communication 
method(s)  that  can  use  its  service.  The  main  design  issue  of  the 
proposed  Telematics  service  platform  is  a  management  of  such 
information  of  all  registered  services,  as  well  as  the 
request/response  XML  schemas.  The  Telematics  service 
platform  consists  of  three  modules:  service  manager, 
communication  manager,  and  platform  operating  manager.  Fig. 
1  shows  the  overall  architecture  of  the  proposed  Telematics 
service  platform,  and  details  of  each  module  will  be  followed. 
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Service  provider  gateway  provides  communication  channels 
between  the  service  platform  and  server  systems  of  service 
providers’.  For  the  interoperability,  HTTP  protocol  is  used  with 
XML-formatted  data,  and  we  are  going  to  support  an 
enhancement  of  TCP/IP  protocol  that  is  widely  operated  in 
industrial  fields  because  of  its  outstanding  performance. 
Service  management  component  provides  a  common  service 
schema,  which  is  a  kind  of  template  schema  for  each  category 
of  service.  In  the  case  of  route  service,  because 
request/response  data  of  many  route  services  are  very  similar, 
the  service  platform  provides  a  generic  request/response 
schema  with  common  data  included.  Then  each  route  service 
provider  may  design  its  own  schema  by  inheriting  the  common 
schema  and  adding  its  own  feature.  To  provide  such  a  common 
service  schema,  we  should  list  and  categorize  possible 
Telematics  servics  including  future  items,  and  design  template 
XML  schema  for  request  and  response  of  each  category.  In  our 
research,  services  are  categorized  into  route-guidance, 
safety/security,  entertainment,  and  Vehicle  Relationship 
Management  (VRM)  currently,  which  can  be  extended  when 
new  category  of  service  is  necessary.  For  each  category  we 
build  service  management  component  correspondingly  as  well 
as  a  common  service  schema. 

In  service  manager,  a  structure  of  information  about 
registered  services  is  included.  With  the  international  standard 
of  Universal  Description,  Discovery,  and  Integration  (UDDI) 
[6],  the  structure  model  basically  contains  business  entity, 
service  entity,  binding  entity,  and  tModel.  With  the  advanced 
functionality  of  the  service  platform,  which  even  provides 
services  to  users  directly,  the  structure  model  is  modified  into 
the  best-fitted  one  for  Telematics  services.  Fig.  2  shows  a  data 
structure  model  that  includes  information  of  a  service  provider 
and  service  itself.  Service  management  component  should  be 
newly  supplemented  when  new  service  category  is  added. 
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Figure  1 .  A  smart  web  platform  for  Telematics  services  consisting  of  service 
manager,  communication  manager,  and  platform  operating  manager 


Figure  2.  Data  structure  model  when  registring  a  Telematics  service 


A.  Service  Manager 

Service  manager  provides  a  management  scheme  where 
each  Telematics  service  is  processed  on  aggregated  service 
categorization  as  well  as  a  communication  connection  between 
the  service  platform  and  service  providers.  It  has  three 
submodules:  service  management  interface,  service  provider 
gateway,  and  service  management  component  for  each 
category  of  service.  Service  management  interface  connects 
service  manager  with  platform  databases  and  other  modules. 


B.  Communication  Manager 

Communication  manager  plays  a  role  of  communication 
channel  between  the  service  platform  and  user  terminals,  which 
receives  and  analyzes  user  request,  connects  inner  modules, 
and  provides  Telematics  services  to  users  through  a  user- 
requested  communication  protocol.  It  has  three  submodules: 
user  gateway,  request  analysis  component,  and  communication 
management  interface.  User  gateway  supports  an  XML  Web 
service  that  takes  advantage  of  Simple  Object  Access  Protocol 
(SOAP)  and  Web  Service  Description  Language  (WSDL)  of 


W3C  [4,  5].  The  open  web  interface  enables  heterogeneous 
terminals  of  users  to  have  an  access  to  the  service  platform  and 
get  valuable  information  with  less  effort.  For  backward 
compatibility,  it  can  also  allow  users  to  send  requests  through 
general  HTTP  protocol.  Request  analysis  component  handles 
users’  queries.  With  the  possibilities  of  heterogeneous  types  of 
user  terminals,  it  analyzes  what  users  want  to  do  and 
recognizes  what  environments  users  are  on,  which  makes 
possible  user-specific  Telematics  services.  Communication 
management  interface  connects  workflows  on  communication 
manager  with  other  modules  such  as  databases  and  service 
manager.  It  is  going  to  include  protocol  recognition  procedure 
for  supporting  multiple  protocol  communication  such  as  SOAP, 
HTTP,  and  TCP/IP. 

C.  Platform  Operating  Manager 

Platform  operating  manager  wholly  controls  system  values 
on  the  service  platform  and  manages  information  on  platform 
databases:  managing  profiles  of  users,  service  providers,  and 
system  administrators,  and  monitoring  the  whole  system.  It  has 
three  submodules:  system  manager,  profile  manager,  and 
statistics  manager.  System  manager  monitors  operating 
performance  of  the  platform  server;  it  checks  CPU  utilization, 
memory  usage,  status  of  databases,  and  so  on.  Profile  manager 
administers  accounts  and  associated  information  concerning 
service  users,  service  providers,  and  service  itself.  Statistic 
manager  gathers  numerical  data  on  service  provision  and 
system  performance.  Statistical  values  per  user,  service 
provider,  and  service  category  can  be  recorded  for  service 
charge.  Though  details  about  charge  are  beyond  the  scope  of 
this  paper,  platform  operating  manager  provides  a  summarized 
form  of  statistical  history  that  can  be  directly  connected  to  a 
commercial  billing  system.  Statistical  values  on  system 
performance  are  recorded  for  stable  operation  of  a  physical 
server. 

III.  Service  Registration  and  Usage 

A.  Service  Registration 

Within  the  framework  of  the  Telematics  service  platform, 
each  Telematics  service  provider  first  should  define  its  own 
XML  schema,  may  be  inherited  from  a  common  service 
schema,  and  prepare  a  conversion  function  that  can  convert  its 
own  data  format  into  the  XML.  Then  the  service  provider 
registers  its  service  by  uploading  request/response  XML 
schema  together  with  general  information  such  as  service  name, 
provider’s  contact  point,  and  connection  link  (URL).  In 
addition,  when  registering  a  service,  the  service  provider 
should  designate  service  category,  response  data  type(s),  and 
supportable  terminal  type(s).  These  three  kinds  of  data  are  used 
for  categorization  and  management  of  service,  and  enable  users 
to  retrieve  available  services  by  data  type  and  terminal  type. 
Fig.  3  shows  an  example  of  a  service  registration  on  a  web 
browser. 

B.  Service  Usage 

With  many  services  registered  and  provided  via  the 
Telematics  service  platform,  a  user  can  freely  use  any  service 
whose  request/response  is  defined  and  registered  by  XML 


schema,  without  needs  to  know  details  of  the  server-specific 
data  format  or  environments.  The  service  user  can  find 
available  services  through  any  terminal  (a  web  browser  in  this 
paper)  by  (1)  connect  to  the  service  platform;  (2)  designate 
terminal  type  and  environment;  (3)  search  a  service  list  that  can 
be  provided  by  the  service  platform;  (4)  select  a  service  from 
the  list;  and  (5)  get  request/response  XML  schema  associated 
to  the  selected  service.  When  searching  a  service,  the  list  of 
available  services  is  filtered  according  to  the  type  of  user 
terminal  type.  Then  the  service  user  gets  information  to  bind  a 
target  service  and  uses  it  by  (1)  prepare  a  request  XML 
document  conforming  to  the  XML  schema;  (2)  send  the  XML 
document  to  the  service  provider  via  the  Telematics  service 
platform;  (3)  get  a  response  XML  document  from  the  service 
provider  via  the  Telematics  service  platform;  and  (4)  analyze 
the  XML  document  to  display  or  use  the  response  data. 


Figure  3.  Service  registration  including  information  of  service  category,  data 
type(s),  and  terminal  type(s)  on  a  web  browser 

In  this  environment,  the  service  platform  plays  a  role  of  a 
service  broker  that  exposes  a  list  of  available  services  to  users. 
It  also  does  a  role  of  a  front  interface  of  service  provider  that 
supports  Bind  procedure  by  (1)  receive  a  raw  format  of  a 
service  data  from  a  service  provider;  (2)  transform  the  raw  data 
into  a  common  XML  format;  and  (3)  provide  the  resulted 
service  data  to  users  directly. 

IV.  Implementation  of  Telematics  Route  Service 

In  this  section,  we  present  a  prototype  of  a  Telematics 
service  and  its  connection  to  the  proposed  Telematics  service 
platform.  Among  Telematics  services,  most  widely  used  one  is 
a  route  guidance  service  (also  known  as  a  car  navigation), 
which  is  spotlighted  as  a  leading  service  in  the  field  of 
Telematics.  Therefore  we  develop  a  prototype  of  route  service 
and  apply  it  to  the  proposed  Telematics  service  platform. 

In  order  to  provide  the  route  service  via  the  proposed 
Telematics  service  platform,  a  standardized  interface  or  XML 
schema  is  required.  Because  there  are  many  servers  and 
consumers  for  route  services  with  different  interfaces  and 
assumptions,  there  needs  to  generalize  common  cases  to 
provide  route  information:  vector-typed  route  with  digital  map; 


image-typed  route  without  digital  map;  text-typed  route  with 
no  graphic  display.  To  integrate  diverse  Telematics  services  in 
a  single  platform,  we  consider  such  cases  when  designing  the 
request/response  schema  and  management  policy  about 
services.  The  Telematics  service  platform  allows  service 
providers  to  register  the  terminal  type  and  supportable  data 
type  in  addition  to  request/response  schema. 

The  service  platform  categorizes  and  manages  the  services 
considering  such  information,  and  provides  the  information 
about  services  when  the  users  retrieve  available  services.  For 
example,  a  user  may  ask  a  query  like:  “I  want  to  get  route 
information  on  my  PDA  with  graphic  display  capability  but  no 
digital  map.  What  is  the  available  route  service(s)  I  can  use?” 
To  handle  the  query,  the  service  platform  should  integrate 
various  types  of  route  service  and  provide  multi-type  route 
service,  without  any  change  of  environment  of  both  service 
providers  and  users.  We  have  investigated  several  existing 
commercial  route  servers,  from  which  we  define  parameters  for 
request  options  and  response  data  as  common  template  XML 
schema  for  route  service.  Of  course,  the  route  server  should 
also  support  a  conversion  function  between  XML  and  its  own 
data  format  as  well  as  original  route-finding  function.  In  a 
demonstration  example,  the  supportable  types  of  this  route 
server  are  vector,  image,  text,  and  photograph,  and  the  XML 
schema  is  designed  to  express  them.  Vector-typed  and  image- 
typed  route  are  requested  with  three  coordinates  designated  as 
start,  intermediate,  and  end  points.  There  are  additionally 
options  including  search  method  and  coordinate  system  of 
underlying  map.  Although  not  shown  in  this  paper,  the  XML 
schema  for  response  data  is  also  defined  for  each  type  of  route. 
Fig.  4  shows  a  web  browser  that  interprets  and  displays  the 
XML-encoded  route  information  provided  by  a  service 
provider  via  the  service  platform. 


Figure  4.  Route  service  executed  on  a  web  browser:  containing  vector, 
image,  photograph-typed  route  information 


V.  Conclusion 

This  paper  proposed  a  smart  web  platform  for  Telematics 
services  in  an  open  environment.  The  platform  consisted  of 
three  core  modules  (service  manager,  communication  manager, 
and  platform  operating  manager)  to  manage  service  providers, 


consumers,  their  connections,  and  service  distribution  on  the 
Web  service  architecture  with  Publish-Find-Bind  mechanism. 
With  this  platform,  service  providers  exposed  their  service  by 
defining  request/response  interface  expressed  as  XML  schema, 
and  the  service  users  could  find  what  services  are  available  and 
how  to  use  them.  This  paper  also  developed  a  prototype  of 
route  service  and  applied  it  to  the  proposed  Telematics  service 
system  to  show  the  entire  service  procedure.  Because  the 
proposed  architecture  adopted  open  interfaces  to  give  an 
extensible  and  casual  access  to  ubiquitous  computing,  users 
could  use  any  service  registered  in  this  platform  in  identical 
manner  without  knowing  or  satisfying  server-specific 
conditions  or  requirements.  In  addition,  the  Telematics  service 
platform  supported  common  service  schemas  for  each  category 
of  service  and  a  verified  data  structure  of  registering 
information,  which  could  shows  an  interoperable  model  toward 
open  environments. 

We  have  currently  tested  the  service  platform  by 
connecting  a  route  service;  however,  it  can  be  generally  and 
easily  extended  to  other  kinds  of  service.  Because  there  are 
many  kinds  of  services  in  the  field  of  Telematics,  designing  the 
efficient  method  for  categorization  of  service  and  defining 
corresponding  common  XML  schema  will  be  researched  as  the 
future  works.  With  the  open  architecture  and  interoperability 
adopted,  the  proposed  Telematics  service  platform  is  expected 
to  contribute  to  spread  Telematics  data  and  activate  related 
industries. 
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